home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text1079.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  2.7 KB  |  70 lines
  1. > > BTW Adding the resolution stuff fixes the problem of changing mode with
  2. > > BlowUP installed. (VSetScreen [or was it VSetMode] switches to the the
  3. > > high-rez TC mode - so I get 640x480xTC on my machine...)
  4. > 
  5. > We are writing a new screen booster. It performs much better than the others.
  6. > It doesn't kill your low-res modes, and it fixes the VSetScreen bug in NVDI.
  7. > It also removes that annoying mono bug where the borders screw up all over
  8. > the place. It even works with MagiC and even Geneva without screwing things up!
  9.  
  10. Great! Sounds good...
  11.  
  12. > It also appears BlowUP doesn't calculate the horizontal registers properly,
  13. > putting annoying limitations on the maximum achievable resolution on most
  14. > monitors. This can result in 'bending' effects and compression near the edges,
  15. > as well as darkened screens and other weird things.
  16.  
  17. Ah, so thats not a limitation of the video hardware? I had just assumed that 
  18. was as high as I could go...
  19.  
  20. > The driver is finished (I'm using it now), but we are still working on the
  21. > res-editing part...
  22.  
  23. ok... so how long will that take? I assume that the res-editing part is not
  24. GEM based? :)
  25.  
  26. > > Yes, I managed to fix the floors - but the walls were all too short for
  27. > > some reason. :/ Maybe this is because I didn't patch the DSP code?
  28. > 
  29. > This is something you might have difficulty with right now. The aspect-ratio
  30. > calculations in BM make selecting a base window size a little more complex
  31. > than it looks. I could remove the aspect ratio stuff but that impacts on
  32. > other areas - RGB monitors in particular...
  33.  
  34. :/ Probably not wise then. 
  35.   
  36. > > My changes to the code are static and you have to reassemble (and patch the
  37. > > DSP code) to get a new resolution, but it shows that there's no real
  38. > > problem doing this.
  39. > 
  40. > > patch the DSP code? I didn't do this??
  41. >  
  42. > Bad Mood is already capable of working out the screen size on it's own - I've
  43. > just omitted to explain how. :)
  44.  
  45. hehehe... :)
  46.  
  47. > I'll explain how to do this after I get a chance to play with it again. It's
  48. > been a while since I looked at it.
  49.  
  50. ok. 
  51.  
  52. > There are probably a few inconsistencies though, like multiple line-width
  53. > variables etc.. this is due to returning to the code for an hour or so after
  54. > several weeks (or months) away from it. Things get a bit disorganized...
  55.  
  56. :) 
  57.  
  58. > > Yep - or perhaps a .cnf [or .ini] file...
  59. >  
  60. > This is what I was working on, but I think it was passed off some time
  61. > ago as being a bit unfriendly. I produced an ini file describing which mode
  62. > to use for which display selection. It also allows you to indicate where software
  63. > emulation of 'big' pixels should be used when low-detail is enabled.
  64.  
  65. well, if you have it partially done, we wouldn't say 'no' to it being completed.
  66. :-)
  67.  
  68. Anthony
  69.  
  70.